Amazon Timestream for InfluxDB がインスタンスのサイズ変更とデプロイ構成（AZ 設定）の変更をサポートしました！
2024.09.062024 年 3 月にリリースされた Amazon Timestream for InfluxDB に待望のアップデートがリリースされました。
このリリースでは 2 つのアップデートが含まれています。
- インスタンスのサイズ変更（拡大または縮小への変更）
- デプロイ設定の変更（シングル AZ または マルチ AZ 構成の変更）
これまではこれらの設定を変更したい場合は、既存データをエクスポートした後に新たなインスタンス環境にインポートする必要があり、運用負荷が高いことが課題でした。
今回のアップデートで、RDS のように各種設定変更がマネージドで行えるようになり運用工数を抑えられるようになりました。
インスタンスサイズの変更を試す
早速試していきます。まずは下記の設定にて DB インスタンスを作成します。
インスタンスの作成が完了したら設定を変更してみましょう。最初はインスタンスサイズを変更してみます。
- インスタンスサイズ:
midium->large - デプロイタイプ: シングル AZ -> スタンバイ付きマルチ AZ
レビュー画面で 「インスタンスを変更」 をクリックして実行します。
アップデート中のステータスは AWS CLI でも確認できます。
下記の結果を見ると、インスタンスサイズは large に変わっていますが、デプロイ構成（deploymentType）はまだ変更されていません。
aws timestream-influxdb get-db-instance --identifier xxxxxxxxxx
{
（中略）
"status": "UPDATING",
"dbInstanceType": "db.influx.large",
（中略）
"deploymentType": "SINGLE_AZ",
（中略）
しばらくすると、ステータスが 「デプロイ対応を更新中」 に変わりました。
CLI の結果も UPDATING_DEPLOYMENT_TYPE となりデプロイ構成の更新中となっていました。
このとき、CLI ではステータスは下記のようになっていました。
"status": "UPDATING_DEPLOYMENT_TYPE",
アップデートが完了すると、次のように変わりました。
"status": "AVAILABLE",
"deploymentType": "WITH_MULTIAZ_STANDBY",
処理にかかった時間
今回は手元の PC から 5 秒おきに温度と湿度データ（自動生成したダミーデータ）を書き込みながら検証しました。
データサイズなどによって変わる可能性がありますが、インスタンスタイプの変更は開始から 5 分程度で完了しました。（データにアクセスできるのは、さらに数分かかる場合があります）
デプロイタイプの変更は「シングル AZ から マルチ AZ」にする場合の方が、逆パターンに比べて時間がかかる結果となりました。（シングル AZ にする場合はインスタンスの削除で済むのに対して、マルチ AZ にする場合はデータの複製とインスタンス作成に時間がかかるためではないかと考えています）
（詳細は本記事にて紹介しております）
変更処理中の書き込みについて
変更の手順はとても簡単でしたが、設定変更中のデータの読み書きについても確認してみました。
検証パターン
検証したパターンは次のとおりです。「1」から順に実施してみました。
- デプロイ構成とインスタンスタイプの変更
- シングル AZ → マルチ AZ 構成へ変更
- インスタンスタイプをスケールアップ
- デプロイ構成とインスタンスタイプの変更
- マルチ AZ → シングル AZ 構成へ変更
- インスタンスタイプをスケールダウン
- デプロイ構成の変更のみ
- シングル AZ → マルチ AZ 構成へ変更
- デプロイ構成の変更のみ
- マルチ AZ → シングル AZ 構成へ変更
- インスタンスタイプの変更
- スケールアップのみ
- インスタンスタイプの変更
- スケールダウンのみ
検証環境
検証は手元の PC から Influx コマンドを利用して書き込みと読み込みを行いました。Inlux コマンドの設定方法は下記を参考にしていだければと思います。
また、名前解決の確認は dig コマンドを使って確認しています。
確認したポイント
このパターンの中で次の点を確認しました。
- DB への読み書きが継続的に可能かどうか（5 秒間隔で実施）
- 読み書きのダウンタイムが発生するか
- DB インスタンスの名前解決の IP アドレスの確認（5 秒間隔で実施）
- アクティブなアベイラビリティゾーンの確認
- デプロイ構成を変更後にどのように変化するか
- 各イベントにかかる時間と全体の処理時間
検証結果
結果内容に関する注意
この検証結果は、5 秒おきに温度・湿度・計測時刻の値を書き込みながら行ったものになります。
そのため、書き込み間隔や DB のデータサイズなどによって結果が変わる可能性があります。結果についてはあくまでも参考情報として読み取っていただけると幸いです。
各種の状況変化の内容
結果を表にまとめてみました
| 検証順 | 検証パターン | 読み書きダウンタイム | IP の変更 | アクティブな AZ の変更 | 全体の処理時間 |
|---|---|---|---|---|---|
| 1 | シングル AZ → マルチ AZ 且つ スケールアップ |
発生 | なし | なし | 約 15 分程度 |
| 2 | マルチ AZ → シングル AZ 且つ スケールダウン |
発生 | 発生 | 発生 | 約 15 分程度 |
| 3 | シングル AZ → マルチ AZ のみ | なし | なし | なし | 約 8 分程度 |
| 4 | マルチ AZ → シングル AZ のみ | なし | なし | なし | 約 3 分程度 |
| 5 | スケールアップ のみ | 発生 | なし | なし | 約 9 分程度 |
| 6 | スケールダウン のみ | 発生 | なし | なし | 約 8 分程度 |
アベイラビリティゾーンの変更は次のようになりました。
| 検証順 | 検証パターン | アクティブな AZ | セカンダリ AZ |
|---|---|---|---|
| 1 | シングル AZ → マルチ AZ 且つ スケールアップ |
1c | 1a |
| 2 | マルチ AZ → シングル AZ 且つ スケールダウン |
1a | - |
| 3 | シングル AZ → マルチ AZ のみ | 1a | 1c |
| 4 | マルチ AZ → シングル AZ のみ | 1a | - |
| 5 | スケールアップ のみ | 1a | - |
| 6 | スケールダウン のみ | 1a | - |
何度か試しましたが、私の環境ではアクティブな AZ が変わる（DB インスタンの IP が変わる）のは、常に「マルチ AZ → シングル AZ 且つ スケールダウン」のパターン時のみでした。
他のアカウントや別のリージョンでは結果が変わるかもしれませんので、ご参考までにとどめていただけると幸いです。
処理時間の違いとその詳細
それぞれの処理時間の詳細は次のようになりました。
- 1. 「シングル AZ → マルチ AZ 且つ スケールアップ」パターン
- 処理にかかった合計時間: 約 15 分間
| 直前のイベントからの経過時間 | イベント内容 |
|---|---|
| - | 開始（ステータス UPDATING ） |
| 約 1 分後 | 読み書きエラーが発生（復旧するまで継続） |
| 約 1 分後 | インスタンスタイプの変更発生 |
| 約 3 分後 | 読み書きエラーが復旧 |
| 約 2 分後 | ステータスが UPDATING_DEPLOYMENT_TYPE に変更 |
| 約 8 分後 | 処理が完了（ステータスが AVAILABLE） |
- 2. 「マルチ AZ → シングル AZ 且つ スケールダウン」パターン
- 処理にかかった合計時間: 約 15 分間
| 直前のイベントからの経過時間 | イベント内容 |
|---|---|
| - | 開始（ステータス UPDATING ） |
| 約 4 分後 | インスタンスタイプの変更発生 |
| 約 2 分後 | 読み書きエラーが発生（復旧するまで継続） |
| 約 2 分後 | InfluxDB インスタンスの IP 変更が発生 |
| 約 2 分後 | 読み書きエラーが復旧 |
| 約 3 分後 | ステータスが UPDATING_DEPLOYMENT_TYPE に変更 |
| 約 3 分後 | 処理が完了（ステータスが AVAILABLE） |
- 3. 「シングル AZ → マルチ AZ のみ」パターン
- 処理にかかった合計時間: 約 8 分間
| 直前のイベントからの経過時間 | イベント内容 |
|---|---|
| - | 開始（ステータス UPDATING ） |
| 約 20 秒後 | ステータスが UPDATING_DEPLOYMENT_TYPE に変更 |
| 約 8 分後 | 処理が完了（ステータスが AVAILABLE） |
- 4. 「マルチ AZ → シングル AZ のみ」パターン
- 処理にかかった合計時間: 3 分間
| 直前のイベントからの経過時間 | イベント内容 |
|---|---|
| - | 開始（ステータス UPDATING ） |
| 約 20 秒後 | ステータスが UPDATING_DEPLOYMENT_TYPE に変更 |
| 約 3 分後 | 処理が完了（ステータスが AVAILABLE） |
- 5. 「スケールアップのみ」パターン
- 処理にかかった合計時間: 約 9 分間
| 直前のイベントからの経過時間 | イベント内容 |
|---|---|
| - | 開始（ステータス UPDATING ） |
| 約 2 分後 | 読み書きエラーが発生（復旧するまで継続） |
| 約 3 分後 | インスタンスタイプの変更発生 |
| 約 2 分後 | 読み書きエラーが復旧 |
| 約 2 分後 | 処理が完了（ステータスが AVAILABLE） |
- 6. 「スケールダウンのみ」パターン
- 処理にかかった合計時間: 約 8 分間
| 直前のイベントからの経過時間 | イベント内容 |
|---|---|
| - | 開始（ステータス UPDATING ） |
| 約 2 分後 | 読み書きエラーが発生（復旧するまで継続） |
| 約 2 分後 | インスタンスタイプの変更発生 |
| 約 2 分後 | 読み書きエラーが復旧 |
| 約 2 分後 | 処理が完了（ステータスが AVAILABLE） |
なお、読み書きがエラーになるタイミングで InfluxDB UI へのアクセスもできなくなりました。ロード中である画面が表示されるようになります。
ここでブラウザを F5 などでリロードすると接続もできなくなりました。
読み書きができるようになると InfluxDB UI にもアクセスできるようになります。
下記のグラフでは、17:15:00 〜 17:15:55 の間はデータの書き込みができていなかったためデータが存在していないことが分かります。
連続的な設定変更はエラーになることがある
デプロイ構成の変更やインスタンスタイプの変更が完了した直後に、再度変更を行おうとすると 「別のデプロイプロセスがまだ起動している」 という旨のメッセージが表示されて、変更を実施できないことがあります。
その場合は、5分ほど時間を置いてからあらためて試してみてください。
そんなに頻繁に変更することはないと思いますが、今回は色々と検証したかったので短時間に何度も変更を行っていたので、この事象に遭遇しました。
最後に
個人的に気になった点を検証してみました。ダウンタイムの発生パターンはおおよそ想定どおりでしたが、デプロイ構成の変更だけでは発生しない点が発見でした。
いずれの AZ 構成の変更の場合でも、セカンダリ AZ 上の DB インスタンスの作成 / 削除が行われることで、既存の読み書きには影響が出ないようになっているように思います。
ただし、もし今回の検証よりも短い時間でダウンタイムが発生していれば、今回の検証では拾えていないかもしれません。また、環境によっては変更にもっと時間がかかる可能性もあるため、利用される際は事前に対象のワークロードを想定した検証を実施されることをおすすめいたします。
とはいえ、待ちに待ったアップデートでしたので Influx DB を利用される場合は、Timestream for InfluxDB もぜひ検討されてみてはいかがでしょうか。
この記事がどなたかの参考になれば幸いです。
